perf(MongoDB): reduce allocations and improve robustness in lock hot paths by joesdu · Pull Request #276 · madelson/DistributedLock

joesdu · 2026-03-27T08:10:02Z

Cache IMongoCollection reference in constructor instead of calling GetCollection on every TryAcquireAsync invocation
Promote immutable BsonDocument sub-expressions (expiredOrMissing, newFencingToken) to static readonly fields; cache newExpiresAt as an instance field (depends on expiry) to avoid rebuilding ~10 BsonDocument objects per busy-wait iteration
Move TTL index initialization to the start of TryAcquireAsync so it is triggered on every acquisition attempt, not only on success
Cache ownerFilter and renewUpdate in InnerHandle constructor; lease renewal (~every 10 s) no longer allocates new filter/update objects
Wrap ReleaseLockAsync in try-catch so network failures during Dispose do not surface unexpected exceptions to callers (TTL index provides eventual cleanup)
Add internal constructor accepting pre-parsed MongoDistributedLockOptions so MongoDistributedSynchronizationProvider can parse options once and reuse the result across all CreateLock calls
Fix stale comment "foo" → "expiresAt" in CheckIfIndexExists
Upgraded Microsoft.SourceLink.GitHub, Microsoft.Build.Tasks.Git, and Microsoft.SourceLink.Common to version 10.0.201 in DistributedLock.ZooKeeper, DistributedLock, and DistributedLockTaker.
Updated System.IO.Hashing to version 10.0.5 and added its dependencies.
Updated MongoDB.Bson and MongoDB.Driver versions to 3.7.1.
Updated System.Diagnostics.DiagnosticSource to version 10.0.5.
Adjusted DistributedLock.Oracle and DistributedLock.SqlServer versions to 1.0.5 and 1.0.7 respectively.
Made various transitive dependency updates to ensure compatibility and stability.

…paths - Cache IMongoCollection<T> reference in constructor instead of calling GetCollection on every TryAcquireAsync invocation - Promote immutable BsonDocument sub-expressions (expiredOrMissing, newFencingToken) to static readonly fields; cache newExpiresAt as an instance field (depends on expiry) to avoid rebuilding ~10 BsonDocument objects per busy-wait iteration - Move TTL index initialization to the start of TryAcquireAsync so it is triggered on every acquisition attempt, not only on success - Cache ownerFilter and renewUpdate in InnerHandle constructor; lease renewal (~every 10 s) no longer allocates new filter/update objects - Wrap ReleaseLockAsync in try-catch so network failures during Dispose do not surface unexpected exceptions to callers (TTL index provides eventual cleanup) - Add internal constructor accepting pre-parsed MongoDistributedLockOptions so MongoDistributedSynchronizationProvider can parse options once and reuse the result across all CreateLock calls - Fix stale comment "foo" → "expiresAt" in CheckIfIndexExists - Upgraded Microsoft.SourceLink.GitHub, Microsoft.Build.Tasks.Git, and Microsoft.SourceLink.Common to version 10.0.201 in DistributedLock.ZooKeeper, DistributedLock, and DistributedLockTaker. - Updated System.IO.Hashing to version 10.0.5 and added its dependencies. - Increased MongoDB.Bson and MongoDB.Driver versions to 3.7.1. - Updated System.Diagnostics.DiagnosticSource to version 10.0.5. - Adjusted DistributedLock.Oracle and DistributedLock.SqlServer versions to 1.0.5 and 1.0.7 respectively. - Made various transitive dependency updates to ensure compatibility and stability.

Copilot

Pull request overview

This PR optimizes the MongoDB-based distributed lock implementation to reduce per-acquire/renew allocations and improve operational robustness (TTL index creation timing, safer dispose behavior), while also updating several NuGet dependencies across the solution.

Changes:

MongoDB lock hot-path optimizations: cache IMongoCollection, reuse BSON sub-expressions, and cache renewal filter/update definitions.
Robustness adjustments: trigger TTL index initialization on every acquisition attempt; make release-on-dispose resilient to transient failures.
Dependency refresh: bump MongoDB driver/BSON, SourceLink/build tooling, DiagnosticSource, System.IO.Hashing, and related transitive pins across projects.

Reviewed changes

Copilot reviewed 18 out of 18 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
src/DistributedLock.MongoDB/MongoDistributedLock.cs	Caches collection/expressions and reduces allocations in acquire/renew; adjusts TTL init timing; swallows release failures on dispose.
src/DistributedLock.MongoDB/MongoIndexInitializer.cs	Makes index-creation helper static and fixes TTL index existence check logic.
src/DistributedLock.MongoDB/MongoDistributedSynchronizationProvider.cs	Parses Mongo lock options once in provider and reuses them when creating locks.
src/Directory.Packages.props	Central version bumps (e.g., MongoDB.Driver, SourceLink, DiagnosticSource).
src/DistributedLock.MongoDB/packages.lock.json	Updates locked dependency graph for MongoDB package changes.
src/DistributedLock/packages.lock.json	Updates locked dependency graph for core package changes (SourceLink/System.IO.Hashing/etc.).
src/DistributedLock.Azure/packages.lock.json	Updates locked dependency graph for Azure package changes and transitive updates.
src/DistributedLock.Core/packages.lock.json	Updates locked dependency graph (notably SourceLink/System.IO.Hashing changes).
src/DistributedLock.FileSystem/packages.lock.json	Updates locked dependency graph for SourceLink/System.IO.Hashing and transitive updates.
src/DistributedLock.MySql/packages.lock.json	Updates locked dependency graph for SourceLink/System.IO.Hashing and transitive updates.
src/DistributedLock.Oracle/packages.lock.json	Updates locked dependency graph for SourceLink/System.IO.Hashing and transitive updates.
src/DistributedLock.Postgres/packages.lock.json	Updates locked dependency graph for SourceLink/System.IO.Hashing and transitive updates.
src/DistributedLock.Redis/packages.lock.json	Updates locked dependency graph for SourceLink/System.IO.Hashing and transitive updates.
src/DistributedLock.SqlServer/packages.lock.json	Updates locked dependency graph for SourceLink/System.IO.Hashing and transitive updates.
src/DistributedLock.Tests/packages.lock.json	Updates locked dependency graph for tests (now only contains net8.0 graph).
src/DistributedLock.WaitHandles/packages.lock.json	Updates locked dependency graph for SourceLink/System.IO.Hashing and transitive updates.
src/DistributedLock.ZooKeeper/packages.lock.json	Updates locked dependency graph for SourceLink/System.IO.Hashing and transitive updates.
src/DistributedLockTaker/packages.lock.json	Updates locked dependency graph (MongoDB driver and other dependency pins).

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

src/DistributedLock.MongoDB/MongoDistributedLock.cs

src/DistributedLock.Tests/packages.lock.json

src/DistributedLock.Core/packages.lock.json

…ockDocument>> for improved initialization

…goDistributedLock

…neAsync

madelson

Thanks for submitting @joesdu ! I've taken a look and left some comments. Please let me know when you're done responding/addressing.

madelson · 2026-03-30T01:09:02Z

src/DistributedLock.MongoDB/MongoDistributedLock.cs

+                { nameof(lockId), new BsonDocument("$cond", new BsonArray { ExpiredOrMissingExpr, lockId, "$lockId" }) },
+                { "expiresAt", new BsonDocument("$cond", new BsonArray { ExpiredOrMissingExpr, this._newExpiresAtExpr, "$expiresAt" }) },
+                { "acquiredAt", new BsonDocument("$cond", new BsonArray { ExpiredOrMissingExpr, "$$NOW", "$acquiredAt" }) },
+                { "fencingToken", new BsonDocument("$cond", new BsonArray { ExpiredOrMissingExpr, NewFencingTokenExpr, "$fencingToken" }) }


If we go this route, seems like we can avoid more allocations here by caching the result of new BsonDocument("$cond", new BsonArray { ExpiredOrMissingExpr, this._newExpiresAtExpr, "$expiresAt" }) instead of _newExpiresAtExpr.

Similarly we could statically cache new BsonDocument("$cond", new BsonArray { ExpiredOrMissingExpr, "$$NOW", "$acquiredAt" }) and new BsonDocument("$cond", new BsonArray { ExpiredOrMissingExpr, NewFencingTokenExpr, "$fencingToken" })

That said, I'm not sure this is safe (see comment above).

If we decide to go with just safe opts, there are more strings as BsonValues to be cached here.

madelson · 2026-03-30T01:18:50Z

src/DistributedLock.MongoDB/MongoDistributedLock.cs

+    private readonly Lazy<IMongoCollection<MongoLockDocument>> _collection;
+
+    // Shared read-only BsonDocument sub-expressions cached to reduce GC pressure on hot paths.
+    // BsonDocument is mutable; these instances must never be modified after initialization.


I'm not convinced that this is a safe optimization. Ultimately we're passing these objects to an IMongoCollection instance which is spawned by an IMongoDatabase. Therefore there is no guarantee of what implementation is being used.

For example, imagine someone has a custom DB implementation that modifies commands going out using the interceptor pattern: this could result in modifying these static datastructures, corrupting the lock.

It is definitely safe to statically cache new BsonDateTime(EpochUtc) since that is immutable. There are also several cases where we're passing values to BsonArray that implicitly get wrapped as BsonValue which results in allocation. For example "$expiresAt", "$fencingToken", and "$$NOW", (note that 0L and 1L should be allocation-free already). These can all be cached safely in BsonValue fields to avoid allocating.
We should at least do the safe optimizations. As for whether we should do the unsafe ones, my question is: How much difference does it make in terms of allocated bytes and time when we do all the unsafe opts instead of just the safe opts?

It would be nice to have a little table:

Optimizations Allocated bytes for 1 (warm) allocate + release Measured time for warm allocate + release

Initial release ??? ???

With just safe optimizations ??? ???

With safe + unsafe optimizations ??? ???

madelson · 2026-03-30T01:19:23Z

src/DistributedLock.MongoDB/MongoDistributedLock.cs

+            "$dateAdd",
+            new BsonDocument
+            {
+                { "startDate", "$$NOW" },


Can save the allocation from converting "$$NOW" to BsonValue (see above)

madelson · 2026-03-30T01:23:48Z

src/DistributedLock.MongoDB/MongoDistributedLock.cs

-    private static UpdateDefinition<MongoLockDocument> CreateAcquireUpdate(string lockId, TimeoutValue expiry)
+    private UpdateDefinition<MongoLockDocument> CreateAcquireUpdate(string lockId)
    {
-        Invariant.Require(!expiry.IsInfinite);


What happened to this check?

madelson · 2026-03-30T01:28:45Z

src/DistributedLock.MongoDB/MongoDistributedLock.cs

-                await this._collection.DeleteOneAsync(filter).ConfigureAwait(false);
+                // Release failure is non-fatal: the TTL index will eventually clean up expired documents.
+                // Swallowing only expected network/write/cancellation failures prevents surprising callers
+                // during Dispose without hiding programming errors (e.g. ArgumentException).


This change should be reverted. The current semantics of distributed lock are that failed releases must not fail silently. This is to make sure bugs that prevent release (e.g. lack of connectivity, lack of permissions, distributedlock bugs) get addressed quickly. Callers who wish to swallow errors may do so by using a try-catch around the dispose call or even wrapping the lock in an error-swallowing version.

madelson · 2026-03-30T01:32:26Z

src/DistributedLock.MongoDB/MongoDistributedLock.cs

+            // Cache the renewal update pipeline (expiry is fixed for the lock's lifetime)
+            this._renewUpdate = new PipelineUpdateDefinition<MongoLockDocument>(
+                new[] { new BsonDocument("$set", new BsonDocument("expiresAt", @lock._newExpiresAtExpr)) }
+            );


Renew probably isn't called on most lock handle instances (since in the wild most locks are released quickly).

Therefore, caching this probaby increases allocations instead of reducing them: it is only a win if we go through multiple renewals of a handle!

My suggestion is to go back to not caching this. Alternatively we could make _renewUpdate a lazily-initialized field that starts as null and inits on the first renewal.

madelson · 2026-03-30T01:35:36Z

src/DistributedLock.MongoDB/MongoDistributedSynchronizationProvider.cs

    private readonly string _collectionName;
    private readonly IMongoDatabase _database;
-    private readonly Action<MongoDistributedSynchronizationOptionsBuilder>? _options;
+    private readonly MongoDistributedLockOptions _options;


This introduces a semantic change. Previously (and I believe for all other lock drivers) each lock instantiation will re-run the options getter which could in theory have side effects.

I'm not necessarily opposed to shifting this behavior, but I'd like to know what the measured impact is since it isn't free in the semantic sense.

madelson · 2026-03-30T01:35:55Z

src/DistributedLock.MongoDB/MongoIndexInitializer.cs


 namespace Medallion.Threading.MongoDB;

+// ReSharper disable once ClassWithVirtualMembersNeverInherited.Global


madelson · 2026-03-30T01:37:04Z

src/DistributedLock.MongoDB/MongoIndexInitializer.cs

                }
+                var keyElement = index["key"].AsBsonDocument;
+                // Check if the first key in the index is "expiresAt"
+                if (keyElement.Contains("expiresAt")) { return true; }


Let's revert this change (other than the comment fix). Feels like we made the code longer but I'm not sure what was achieved. Am I missing something?

madelson · 2026-03-30T01:39:21Z

src/Directory.Packages.props

    <PackageVersion Include="Microsoft.CodeAnalysis.PublicApiAnalyzers" Version="3.3.4" />
    <PackageVersion Include="Azure.Storage.Blobs" Version="12.19.1" />
-    <PackageVersion Include="MongoDB.Driver" Version="3.5.2" />
+    <PackageVersion Include="MongoDB.Driver" Version="3.7.1" />


What's the reason to bump this to 3.7.1? Generally I'm slow to update dependencies since we're just setting a minimum version and consumers can go as high as they like. I like to choose stable releases (this one is only 11 days old) unless there's something really compelling from the new version that is relevant to distributedlock consumers.

Copilot AI review requested due to automatic review settings March 27, 2026 08:10

Copilot started reviewing on behalf of joesdu March 27, 2026 08:10 View session

Copilot AI reviewed Mar 27, 2026

View reviewed changes

joesdu added 3 commits March 27, 2026 16:21

fix(MongoDB): change collection field to Lazy<IMongoCollection<MongoL…

1194c25

…ockDocument>> for improved initialization

refactor(MongoDB): improve code clarity and exception handling in Mon…

4c3da54

…goDistributedLock

fix(MongoDB): avoid using disposed CancellationTokenSource in DeleteO…

b6e8275

…neAsync

madelson requested changes Mar 30, 2026

View reviewed changes

Optimizations	Allocated bytes for 1 (warm) allocate + release	Measured time for warm allocate + release
Initial release	???	???
With just safe optimizations	???	???
With safe + unsafe optimizations	???	???


		namespace Medallion.Threading.MongoDB;

		// ReSharper disable once ClassWithVirtualMembersNeverInherited.Global

Conversation

joesdu commented Mar 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

madelson left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

joesdu commented Mar 27, 2026 •

edited

Loading